1. Technical Field
The subject technology relates to a method for scheduling logical resources in cloud platforms. In particular, aspects of the technology provide systems and methods for utilizing a filter scheduler with multiple filter chains to enable joint, service-spanning scheduling among multiple infrastructure services.
2. Introduction
Through virtual machine technology, cloud computing is changing the landscape of network-based services by offering its customers (also known as “tenants”) a means to use a service provider's virtualized computing assets, such as virtual processors, virtual storage, and virtual network resources, instead of having to purchase and own all of the necessary equipment outright. In particular, Infrastructure-as-a-Service (IaaS) cloud platforms may offer infrastructure services such as compute service(s), networking service(s), and storage service(s) to the tenants. They can provide logical resources that can be created on-demand by cloud users via, for instance, a representational state transfer (REST) application programming interface (API). Examples of such logical resources are virtual machine (VM), network, router, and block storage.
Under the cover, the logical resources can be implemented and materialized by the IaaS platform using servers, VMs, virtual/physical network devices, and storage devices. Each infrastructure service may include a resource management function and a scheduler function, whereby the logical resources can be mapped to the underlying physical resources that host them. To minimize cost, the IaaS providers may want the resource management and scheduling functions to make as efficient use of the underlying resources as possible. The cloud application utilizing the logical resources may also have specific performance requirements.
However, instantiating a logical resource may often require that the resource managers and the schedulers in multiple infrastructure services to work in concert. For example, in order for a VM to serve as a logical router, the VM may require information from both a network service and a compute service, each equipped with its own scheduler. If these schedulers execute their tasks independently of each other in a non-collaborative way, the utilization of the services may be poor or performance requirements may not be fulfilled.
Traditionally, one way to solve this problem is to use a common scheduler for multiple IaaS services. This solution, however, creates a tighter coupling among all of the involved IaaS services. Thus, having a central scheduler may increase inter-service control traffic and state sharing, resulting in higher inter-service dependencies. This may also complicate the evolution of the services as they are typically developed by separate development teams.
Another traditional method of resolving the problem is to use a hierarchy of schedulers. However, this approach is not without its complications. In order to perform scheduling in a sufficiently efficient manner, the scheduler that sits on top of the individual service schedulers may require fairly detailed service-specific knowledge of all the subordinate schedulers and services. Thus, the scheduler on top easily ends up merely performing a serialized invocation of the service-specific schedulers. In other words, the top-level scheduler can be relegated to performing more of an orchestration task rather than a true joint, service-spanning scheduling.